Many decisions made by business enterprises can be represented by one or more business rules. As used herein the term “rule” refers to one or more actions or operations that are performed upon the satisfaction of one or more conditions. Thus, a “business rule” refers to one or more business actions or business operations that are performed upon the satisfaction of one or more conditions. For example, in the context of a financial company that issues credit cards, the process for determining whether to offer a credit card to a particular individual based upon particular financial or demographic information can be represented by one or more business rules.
Business rules are important because they allow business decisions to be automated using computer software. The business logic and conditions defined by business rules are embodied in computer software. Referring to the prior example, it is not uncommon for financial companies to automate, using computer software, the decision about whether a credit card should be offered to a particular individual. Conventionally, these types of computer systems use complex customized software to implement business rules.
A significant problem with using custom software to implement business rules is that the people in business organizations who decide on changes to business rules generally cannot themselves implement those changes in the computer software. When business logic or conditions change, the computer software must be updated to reflect the change. For example, in the context of issuing credit cards, if the minimum salary requirement is changed from X to Y, then the software must be manually updated to reflect the change in the minimum salary requirement from X to Y. Updating computer software generally requires technical expertise that the business people who decide the business rules simply don't have. These people are often financial analysts or high-level managers. Updating the software typically involves changing values in source code or data files and then “rebuilding” the software, which requires recompiling source code to generate object code and then linking the object code with libraries of other object code to generate a new runtime executable.
Some companies use a database system to store condition values so that the condition values can be updated and used by application software without having to rebuild the application software. When condition values are updated, the software retrieves the updated values from the database. This solves the problem of having to rebuild application software when condition values change, but still does not allow business people who define business rules and changes to implement those changes themselves. Furthermore, databases are generally not capable of storing the complex business logic required by business rules. Rather, the business logic must still be embodied in the complex custom software. Hence, changing business logic rules requires updating the custom software, which cannot be done by non-technical personnel.
Based upon the need for non-technical people to be able to update business rules and applications that use the business rules, an approach for updating business rules and applications that use them that does not suffer from limitations of prior approaches is highly desirable.